When developing software, that is, programs for computers, improving the quality of the software code is an ongoing objective. This applies not only in relation to ensuring the functionality of the software, but also for example in relation to its maintainability and intelligibility. In particular it is difficult to achieve a sufficiently high software quality when the software is extensive, that is, there is a large volume of source code, particularly in order to cover the desired functionality. Moreover there is often a large number of explicit and implicit informal requirements, not all of which are known to the participating developers in the same degree, and are therefore not taken sufficiently into consideration in the course of development. Furthermore there is frequently intense time pressure for completion and delivery of the software.
Quality models for assessing the quality of software have already been developed, enabling quality to be assessed according to predetermined criteria. Such a quality model is contained in for example the German industrial standard, DIN, ISO 9126, Software engineering—software product evaluation, product quality and guide to quality in use, 1991. This standard defines metrics to be used in measuring and specifying software quality. Going beyond this standard, the following list gives some examples of object-oriented metrics: Depth of inheritance tree, DIT, number of children, NOC, coupling between objects, CBO, weighted methods per class, WMC, response for class, RFC, message passing coupling, MPC, lack of cohesion in methods, LCOM, etc. These metrics can be used to measure properties of object-oriented software at the level of classes and methods.
Metrics are indicators of errors contained in the software and in many cases are meaningful to only a limited extent. They are very strongly dependent on the technological boundary conditions of the computer systems used, such as memory capacity, reaction time, throughput, restart capability following a halt, update capabilities, etc. It is therefore also necessary to have the quality of the software assessed by experts who personally read through at least some parts of the source code in a more or less structured manner. In this way potential sources of error are pinpointed, documented and ways of improvement suggested, preferably leading to correction of the software error. However, due to rapidly growing volumes of source code, a high linkage between systems and their application environments, short development times, often locally distributed development capacity and last but not least a lack of experts, this procedure is increasingly impracticable and open to error.
So-called refactorings or refactoring steps are known from Martin Fowler, “Refactoring: Improving the Design of Existing Code”, Addison-Wesley, New York, 1999. Refactoring steps are function-acquiring transformations of the source code which can lead to an improvement in the intelligibility of the source code. Examples of such refactoring steps include: Extract method, in order to extract a method (subroutine) from the code; inline method, in order to insert a method into the code; move method, in order to move a method from one class to another; move attribute, in order to move an attribute from one class to another; extract class, in order to generate a new class and move certain cohesive attributes and methods to this new class; inline class, in order to move the members of a class into another class and delete the old class, etc.